I found this #1585, #521
Here how I understand was annotation FederationSource, but now smallrye graphql not contains it. The logic there intersects with my PR. For example, in NodeJS federation router itself sends requests about what and what fields it needs. And there it can be any object (list of parameters).
At the moment I have not yet come up with how creeate a universal wrapper object (method must have all required 'primitive' params. see test). With these changes, the router can obtain the required data. And most importantly, queries are not published to the schema. Exmaple, service extends external type other service

extend type Type key('id') {
  id: String external
  name: String external
  value: String requries('name')
}

If you request a field value will be sended request like

_entities(representations: { id: "id", name: "name", __typename: "Type" }) {
  __typename
  ... on ExtendedType {
    value
  }
}

value extended field. It turns out you need to make 2 requests, by id (default and may be query), and id and name (value requires field name).
And if you publish so many queries to the schema, it can become very large. And it may not be necessary for requests to be available exclusively to the federation router.
It can be useful only for federation

It would probably be nice to have such an option.

record Vars(String id, String name){}
@Resolver
Product find(Vars vars){
   ...
}

and allow pass queries like

_entities(representations: { id: "id", name: "name", __typename: "Product " }) { __typename  ... on ExtendedType { id name value } }

_entities(representations: { id: "id", __typename: "Product " }) { __typename  ... on ExtendedType { id} }

in one method. or maybe it is wrong idea.

Unfortunately, I couldn’t figure out how to make one general type. Too much magic

Needs simple changes in quarkus (add resolvers operations here)

Hi @jmartisk, @t1. What do you think about it?
For example, This example in JS. And in Spring

Hi, sorry a bit busy, but I'll try to review at the beginning of next week...

This will require changes that are present in #2184

@jmartisk Hi. I’ve probably already tired you, but please look at this PR too.
In short, this will allow to avoid creating a bunch of @Query for federations, while calmly expanding the types.
For example, there is a service users that implements the User type. There is a status-user service that extends the User type with the blocked field. With the current approach, in the second service requires creating @Query which will be displayed in the general schema, although such a request may not carry any logic separately.

For this PR, it also wouldn’t hurt to add quarkus to the @Resolver index (in the same branch that you did for 2.11. I can do it later when we discuss this PR)

Ok, would you also please create a PR to my Quarkus branch (https://github.com/jmartisk/quarkus/tree/smallrye-graphql-2.11) with the Quarkus-side change and preferably also a simple test that runs with Quarkus?

Added changes and a couple of simple tests to your fork and create PR. After accepting the PR for quarkus, need restart the pipeline here, to be sure everything is ok.

Ok, merged the Quarkus part, now re-running the CI here... Thanks!

@jmartisk It seems like I did everything, made all the necessary corrections.

Thanks!